kIDL: Interface Definition Language for the Kernel

This project is part of a larger project whose goal is to decompose the Linux kernel. The Linux kernel is a sharedmemory environment, and decomposing the Linux kernel provides security by confining the effects of attacks. The Lightweight Capability Domains project [6] is decomposing the Linux kernel into a share-nothing environment. In this environment, subsystems which previously existed in a sharedmemory environment will now exist in their own sharenothing isolated domains. Because processes now execute in separate address spaces, functions cannot be directly called between domains. To allow these subsystems to continue to interact in this new environment, new code must be written that makes function calls across address spaces. This “glue” code marshals parameters from one address space to another, and then calls the function as if the caller was in the same address space. This code must be written for each individual function that we would like to use across domains, and this code is highly similar between functions. To automate this code generation an Interface Definition Language (IDL) is used. An IDL allows a user to describe the functions they would like to export for other domains to use, and then an IDL compiler automatically generates the glue code. We created an IDL compiler that automatically generates this glue code. Because the Linux kernel is written in C, this IDL is targeted for the C language, and we created a new IDL syntax for describing C interfaces. Like previous IDLs’ syntaxes, this new IDL syntax allows users to describe data structures, functions, and remote data structures. From an IDL specification, two pieces of code are generated: code for the function caller, caller glue code; and code for the function provider, callee glue code. The caller glue code is used by anyone who wishes to call any of the exported functions. This glue code is called in place of the real function, and handles the marshaling of parameters across address spaces, and the remote function call using interdomain communication (IDC). The callee side glue code is used by whomever is exporting the functions described in the IDL. This glue code intercepts the function calls meant for the callee, and then unmarshals the parameters and makes the real function call, returning the result to the caller using IDC. The code generated from the IDL is described in greater detail in section III. We want to allow two separate domains to synchronize two separate copies of the same data, so the same piece of data can be used without passing the entire data structure every function call; only the pieces of the data structure which have changed must be passed. Since, pointers to structures are often passed during function calls, this allows the minimal amount of data to be copied between address spaces during each function call. To support this, we have created the concept of a container. A container is a structure which contains the original piece of data we would like to synchronize, as well as a reference to our local container and a reference to the remote container. These container references allow one domain to refer to another domain’s data during a function call. To support this idea, the IDL syntax allows the user to specify container lifetimes with new syntax. Containers will be explained in greater detail in section III-C. In the following sections I will explain the syntax of the IDL, the glue code which is generated, and the purpose of this glue code. The IDL compiler currently generates the caller and callee glue code functions, as well as the container structures. It also generates the extra code required to implement cross-domain function pointer calls.